Knowing the performance of a path, connection or unicast bearer across one or more IP networks is valuable information to network operators and application users. The notion of active probe based sampling of network paths or bearers has been established as a viable methodology for making inferences about the state of a bidirectional subscriber connection, often made of one or more unidirectional tunnels responsible for encapsulating and carrying the forward (downlink) and reverse (uplink) user data traffic to its destination over one or more networks. Connectivity, packet delay, packet loss and User Datagram Protocol (UDP) throughput measurements can be used for troubleshooting, network characterization and application performance estimation on a per-subscriber basis.
User traffic, including any test traffic, transmitted over an IP network and/or encapsulated into a subscriber bearer may not be easily inspected or intercepted by the intermediate nodes. The intermediate nodes are not intended to process or terminate application or test traffic that is destined to the subscriber device. Also, the intermediate nodes may not be aware of the user data traffic and associated applications transmitted over subscriber tunnels. Examples of the tunnels include but are not limited to GTP-U as described in “GPRS Tunneling Protocol User Plane (GTPv1-U), TS 29.281,” incorporated herein by reference and GRE as described in “Key and Sequence Number Extensions to GRE, RFC 2890,” incorporated herein by reference. The processing of all traffic encapsulated into tunnels can cause significant performance degradation on the intermediate nodes because they are optimized to forward packets from one tunnel to another based on tunnel identifier information provided in the packet header.
The standard Two-Way Active Measurement Protocol (TWAMP) test protocol, described in “A Two-Way Active Measurement Protocol (TWAMP), RFC 5357” which is incorporated herein by reference, is a good non-limiting example of an active probing protocol that can be used to exchange test packets between two hosts or endpoints. For example, a two-way connectivity test can be initiated between a test traffic controller, located in the core network, and a specific subscriber device to determine if the end-to-end bearer or connection to the subscriber has been properly initialized and if the intermediate nodes are properly forwarding the user data traffic on the appropriate tunnels. The same test can also be used for detecting Internet Protocol (IP), Open Systems Interconnection (OSI) layer 2 (L2) or layer 1 (L1) connectivity or performance issues within the underlying packet transport networks.
One of the problems associated with the aforementioned connectivity test is the test traffic transmitted over the subscriber bearer or directly over the IP network, destined to the subscriber address, is only processed by the subscriber connection endpoints. The endpoint is typically a subscriber device. However, most subscriber devices do not, or should not, support the capability to respond to various kinds of test traffic. Considering another possible issue, sending ongoing operator initiated test traffic to a subscriber device can have legal ramifications for the network operators.
Assuming a subscriber device is capable and authorized to reflect test traffic, sending and receiving test traffic over the complete subscriber connection is useful information but often generates all or nothing results, i.e., a two way connectivity test will result in either the subscriber being reachable or the subscriber being unreachable. If the subscriber is unreachable, the test or measurement will not specify the location of the connectivity or performance issue along the end-to-end subscriber connection. A subscriber connection often involves two or more intermediate nodes acting as IP hops or as tunnel traffic forwarders. The intermediate IP hop or the tunnel traffic forwarding nodes can be the cause of the failure, either internal or external failure, or performance issue and may not necessarily have raised an alarm or sent a notification to warn the operator.
Another attempt for determining the performance of a path is illustrated in United States Patent Application Publication 2011222414A1 titled “Method and Apparatus for Active Probing of Tunneled Internet Protocol (IP) Transmission Paths” which teaches in part the use of a user equipment emulator as a substitute for a subscriber device endpoint which may avoid sending operated initiated test traffic to a subscriber device. Unfortunately, the user equipment emulator approach will generate results even when a real subscriber device is unreachable, providing inaccurate data.
Accordingly, it would be desirable to provide devices, systems and methods for path performance determination in such systems that avoid the afore-described problems and drawbacks.